01. Agent 的基础概念与总体方法论

本章高频面试题

什么是 Agent？它和普通大模型问答、RAG、Workflow 有什么区别？
Anthropic 提出的”Workflow vs Agent”分野是什么？什么时候应该选 workflow 而不是 agent？
为什么说 Agent 工程的核心问题不是”模型够不够聪明”，而是”系统是否足够可靠”？
一个生产级 Agent 系统通常由哪些模块组成？
为什么 Agent 系统比普通 Chatbot 更强调状态、事件流、可恢复和可观测性？
如何从 0 到 1 设计一个 Agent 系统，而不是只做一个 Demo？
Agent 系统里哪些问题应该靠 Prompt 解决，哪些问题必须靠架构解决？
单 Agent、多 Agent、Sub-agent 怎么选？
Agent 系统的成本和延迟怎么治理？

1. 什么是 Agent

先说最朴素的定义。

如果一个系统只是：

接收用户输入
调一次模型
返回一段答案

那它更像一个”LLM 应用”或者”问答应用”，还不算严格意义上的 Agent。

通常我们说一个系统是 Agent，至少意味着它具备下面几种能力中的多种：

能根据目标自主分解任务
能调用外部工具
能在多步执行中维护状态
能根据中间结果调整后续动作
能在失败时重试、降级或重规划
能跨轮次保留一部分短期或长期记忆

所以可以把 Agent 理解成：

一个围绕”目标达成”而不是”单次回复”设计的 LLM 驱动系统。

2. Agent 和几个常见概念的区别

2.1 Agent 和普通 LLM 问答的区别

普通 LLM 问答更像”一问一答”。 Agent 更像”接到任务后，自己规划、查资料、调工具、更新状态、产出结果”。

区别主要在这里：

普通问答关注单次输出
Agent 关注多步执行
普通问答的输入通常只是 prompt
Agent 的输入还包括工具、状态、记忆、规则和执行上下文

2.2 Agent 和 Workflow 的区别（Anthropic 的经典分野）

Anthropic 在 Building Effective Agents 里给出了一个很干净的分法：

Workflow：LLM 和工具沿着开发者预先写死的路径执行，分支和步骤都是显式代码
Agent：LLM 动态决定下一步做什么，自己选工具、自己控制执行流程

两者不是二选一。现实系统里最稳的做法是：

用 Workflow 承担确定性部分，用 Agent 承担高不确定性决策部分。

几条工程选择原则：

能用 workflow 就别用 agent。Agent 的每一步决策都有延迟、成本和不确定性，只有在”路径真的无法预定义”时才值得上
workflow 的可预测性是资产。调试、评估、回放都便宜一个数量级
把 agent 夹在 workflow 里。一个常见的生产模式是：workflow 做意图分类 → 路由到某个 sub-agent 解决开放任务 → workflow 做结果校验/落库

2.3 Agent 和 RAG 的区别

RAG 是 Retrieval-Augmented Generation，也就是”检索增强生成”。

RAG 是一种能力，不是完整的 Agent。

一个 Agent 可以使用 RAG，但 Agent 不等于 RAG：

“检索文档后回答问题”是 RAG 应用
“先判断问题类型，再检索多个来源，再调用数据库，再写总结，再发邮件”是 Agent

当 RAG 加入动态决策（比如”要不要再查一次”、“换个检索词”），就演化成 Agentic RAG，这在第 4 章会展开。

3. 为什么 Agent 工程的重点是可靠性

很多人学习 Agent 时，会下意识把问题理解成：

“我该怎么让模型更聪明？”

但真实工程里，更大的问题通常不是聪明，而是稳定。

一个 Demo 可以靠一次好运跑通。一个生产系统必须回答这些问题：

如果工具超时怎么办？
如果模型选错工具怎么办？
如果上下文太长怎么办？
如果用户刷新页面怎么办？
如果需要人工审批怎么办？
如果线上行为异常，怎么排查？
如果升级模型后效果退化，怎么发现？

所以 Agent 工程更像”系统工程”，而不是”Prompt 艺术”。

更具体一点，衡量一个 Agent 是否”可靠”的常用指标：

任务成功率（task success rate）：端到端完成目标的比例
trajectory 有效长度：完成任务用了多少步——步数爆炸往往是规划问题
p95 / p99 延迟：Agent 尾延迟通常比中位延迟糟糕得多
单次任务 token 成本：模型的 autonomy 越高，这个数字越难控
人工介入率：多少比例的 run 最终需要人接管
失败可诊断率：线上失败里有多少比例能通过 trace 快速定位

如果这些指标没人看，系统大概率在”看起来能用”和”真的能用”之间游荡。

4. 一个生产级 Agent 系统通常包含什么

建议把一个 Agent 系统拆成下面这些模块来看：

Model Gateway 模型路由、模型回退、usage 归因、prompt caching 控制。一个好的 gateway 能让你把”模型选型”和”业务逻辑”解耦。
Prompt Layer 系统提示、开发者提示、工具说明、输出格式说明。Prompt 必须版本化，并且对 prompt caching 友好（见第 3 章）。
Planning Layer 任务分解、步骤编排、重规划、失败恢复。
Tool System 外部能力接入层。对内接自研 registry，对外可接 MCP server。
Skill System 可复用的方法模块，按需加载（progressive disclosure，见第 2 章）。
Context Layer 当前任务状态、历史消息、检索结果、环境配置、权限信息——按槽位组装而不是糊成一段。
Memory Layer 短期记忆（state）和长期记忆（事实/情节/关系），配写入策略和遗忘机制。
RAG / Retrieval Layer Hybrid retrieval + rerank，带 metadata filter；知识来源不一定是向量库，也可能是业务 API。
Execution Runtime 驱动循环、状态更新、并发、超时、重试和持久化。推荐用 durable execution 承载（LangGraph、Temporal、Inngest、Restate）。
Event Stream 把运行过程实时推给前端和监控系统，可恢复可回放。
UI / Human-in-the-loop 用户界面、人工审批、断点恢复、调试界面。
Observability & Evaluation Tracing、metrics、logs、feedback、evals。OpenTelemetry GenAI semantic conventions 是新的工业基线（当前处于 experimental 状态）。
Guardrails & Security 权限边界、工具安全、输入/输出/上下文/路径多层守护、供应链安全、合规审计。

5. 单 Agent、多 Agent、Sub-agent 的取舍

这是 2025-2026 最容易踩坑的设计决策。

几条来自生产的经验（综合 Anthropic、Cognition 等团队的公开分享）：

默认单 agent。一个 agent + 足够好的 tool/skill 系统能解决绝大多数任务。
Multi-agent 最大的坑是”上下文共享”。多个 agent 并行执行时，如果彼此看不到对方的关键决策，最终输出往往冲突或重复劳动。Cognition 的 Don’t Build Multi-Agents 直接把这点点名了。
Sub-agent 的本质是”隔离上下文”，不是”扩容并行”。当某个子任务会产生大量过程性噪音（长文 PDF 深读、大量中间搜索），把它封装成 sub-agent 让主 agent 只看摘要汇报，这是值得的。
并行只在真正无依赖的分支上开。多源检索、多候选评估可以并行；有因果依赖的步骤强行并行只会制造 race condition。
“多 agent 交流”前，先问为什么不能做成 workflow。Agent 之间的自由对话成本极高，大多数时候一个结构化 handoff contract 就够了。

6. 一套适合工程落地的方法论

下面这套方法论比较适合中大型 Agent 项目，也适合面试时回答”你会怎么从 0 到 1 设计一个 Agent 系统”。

第一步：定义任务边界

先明确四件事：

目标是什么
成功标准是什么（可度量，不要写”让用户满意”）
哪些动作允许自动执行
哪些动作必须人工确认

很多 Agent 项目失败，不是因为模型太弱，而是因为任务边界一开始就没定义清楚。

第二步：先判断需不需要 Agent

并不是所有任务都需要 Agent。

下面几类任务通常不需要完整 Agent：

固定模板生成
明确映射的分类任务
单次检索问答
严格线性的几步流程

这些场景很多时候用普通后端逻辑、工作流引擎、规则引擎就够了。

更适合 Agent 的任务通常有这些特征：

目标抽象，不是单步完成
路径不固定
需要多工具协作
需要根据中间结果动态调整

第三步：把不确定性和确定性拆开

这是最重要的一条实践原则。

不要把整个系统都交给模型。应该拆成两部分：

确定性部分：用代码、工作流、状态机、规则去做
不确定性部分：交给模型去判断、规划、总结、选择

例如：

“订单能不能退款”是规则系统
“如何向用户解释退款失败原因”交给模型
“退款金额不能超过订单金额”是 server-side 校验，不是 prompt 提示

第四步：先设计状态，再设计 Prompt

很多团队一上来就写 prompt，但长期最稳的方法是：

先定义系统状态（可持久化、可检查、可回放的结构化 state）
再定义事件（什么情况下 state 如何改变）
再定义工具输入输出
最后才写 Prompt

因为 Agent 真正运行时依赖的不是一句话，而是状态转移。

第五步：从第一天就做成可恢复的

生产级 Agent 一定要考虑：

中途失败后能不能恢复
工具超时后能不能重试
用户刷新页面后能不能继续
人工审批后能不能从原位置恢复
进程崩溃/机器迁移后能不能从 checkpoint 继续

这意味着执行 runtime 的选择从一开始就很关键。LangGraph 的 checkpointer、Temporal/Inngest/Restate 的 durable execution、或自研 event-sourced state machine，都是为这一点存在的。“先跑起来再补恢复”在 Agent 场景里几乎永远翻车。

第六步：默认认为你需要可观测性

任何一个稍微复杂的 Agent，上线后都必须能回答：

这次 run 走了哪些步骤
每一步用了多少时间、多少 token、多少钱
哪个工具失败了
模型为什么选了这个工具
最终失败是 prompt 问题、上下文问题、工具问题还是数据问题

所以不要把 tracing、评估、日志当成”以后再说”的东西。生产 Agent 建议直接走 OpenTelemetry GenAI semantic conventions 这套事实标准（目前 experimental 状态，通过 OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental 启用），再叠加 LangSmith / Langfuse / Phoenix 这类专门的 LLM tracing UI。

第七步：成本与延迟工程要和正确性同等重要

Agent 有个天然的经济学问题：token 和步数的乘积决定单次任务成本，autonomy 越高这个乘积越难控。几条实操手段：

模型路由：简单子任务用 Haiku 级小模型，决策/规划用 Opus 级大模型
Prompt caching：把稳定的 system prompt / tool schema / 长文档前缀缓存起来（Anthropic 的 cache 读只要基础价的 0.1x）
Context budget：显式给上下文设预算，超过就触发 compact 或 sub-agent
Circuit breaker：单 run 步数/token/花费超限即中断，避免”失控 loop”
Trajectory 回归：把”同样任务多用了多少步”当成核心回归指标

7. Agent 工程中最常见的误区

误区一：把 Prompt 当万能解法

Prompt 很重要，但它不能替代：

状态机
校验
权限边界
错误恢复
检索系统
事件流

误区二：所有工具都直接给模型

工具一多，误调用率会明显上升。正确做法是 progressive disclosure（catalog + 按需加载）+ 动态裁剪（见第 2 章）。

误区三：只做成功路径

Demo 最容易只考虑 happy path。但生产问题往往来自：

API 超时
结果格式错误
工具不可用
检索为空
消息过长
用户取消任务
幂等重复调用

误区四：只有聊天，没有状态

一旦任务跨多步、多工具、多回合，纯聊天历史通常不足以支撑稳定执行。你需要显式状态，而不仅是 message history。

误区五：没有评估就迭代

Agent 系统迭代非常容易”看起来更聪明，实际上更不稳定”。没有 eval 和 tracing，几乎不可能长期优化。

误区六：默认就上 multi-agent

看到”复杂任务”就拆 agent 是 2025 最高频的错。先问：这能不能用一个 agent + 更好的 tool/skill 完成？能不能用 workflow + sub-agent 完成？大多数答案是”能”。

8. 面试里可以怎么总结这一章

如果面试官问你”Agent 系统开发最重要的方法论是什么”，一个比较好的回答是：

我会先判断问题是否真的需要 Agent——能用 workflow 解决的就别用 agent。接下来把系统拆成确定性和不确定性两部分：确定性由工作流、状态机、规则和校验负责，不确定性才交给模型。然后我会优先设计状态、工具边界、上下文组织、错误恢复和事件流，而不是一开始只写 Prompt。执行层从第一天就用支持 checkpoint / durable execution 的 runtime，观测层走 OTel GenAI 规范配合 LLM-specific tracing。单 agent 够用就不上 multi-agent，成本/延迟/trajectory 长度当核心指标看。因为生产级 Agent 的核心不是一次跑通，而是可恢复、可观察、可评估、可演进。

9. 本章方法论小结

Agent 是面向目标达成的多步系统，不是单次问答
不是所有问题都需要 Agent，能 workflow 就别 agent
Workflow 和 Agent 通常应该组合，而不是互斥
可靠性比”看起来聪明”更重要——任务成功率、trajectory 长度、p99 延迟、成本是核心指标
先设计状态，再设计 Prompt
只把不确定性部分交给模型
从第一天就做成可恢复、可观测、可评估的
默认单 agent，sub-agent 只为隔离上下文而存在，multi-agent 前先自证必要性
生产级 Agent 是系统工程，不是提示词魔法